apt-cache show mscgen-dbgsym grep ^Build-IdsThe latter assumes that you have the debug mirror in your sources list. [3] Efficiency here being features people rarely override/disable.
No comment Liked this article? Click here. My blog is Flattr-enabled.
ssh people.debian.org 'grep -A 10 YOURNAME ~lucas/public_html/qa-20151226/*ddlist'
ssh alioth.debian.org 'grep -A 10 YOURNAME ~lucas/qa-20151226/*ddlist'
the meaning of the lists is:
No comment Liked this article? Click here. My blog is Flattr-enabled.
Week 1 | Week 2 | Week 3 | Week 4 | Week 5 | Week 6 | Week 7 | |
---|---|---|---|---|---|---|---|
# Packages | 10 | 15 | 10 | 14 | 10 | 9 | 21 |
Total | 10 | 25 | 35 | 49 | 59 | 68 | 89 |
openocd.cfg
that contained:
source [find interface/buspirate.cfg]
buspirate_port /dev/ttyUSB0
buspirate_vreg 1
buspirate_mode normal
transport select swd
source [find target/stm32f1x.cfg]
My BP has the Seeed Studio probe cable, so my hookups look like this:
That s BP MOSI (grey) to SWD IO, BP CLK (purple) to SWD CLK, BP 3.3V (red) to FST-01 PWR and BP GND (brown) to FST-01 GND. Once that was done I fired up OpenOCD in one terminal and did the following in another:
$ telnet localhost 4444
Trying ::1...
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
Open On-Chip Debugger
> reset halt
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0xfffffffe msp: 0xfffffffc
Info : device id = 0x20036410
Info : SWD IDCODE 0x1ba01477
Error: Failed to read memory at 0x1ffff7e2
Warn : STM32 flash size failed, probe inaccurate - assuming 128k flash
Info : flash size = 128kbytes
> stm32f1x unlock 0
Device Security Bit Set
stm32x unlocked.
INFO: a reset or power cycle is required for the new settings to take effect.
> reset halt
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0xfffffffe msp: 0xfffffffc
> flash write_image erase /home/noodles/checkouts/gnuk/src/build/gnuk.elf
auto erase enabled
wrote 109568 bytes from file /home/noodles/checkouts/gnuk/src/build/gnuk.elf in 95.055603s (1.126 KiB/s)
> stm32f1x lock 0
stm32x locked
> reset halt
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x08000280 msp: 0x20005000
Then it was a matter of disconnecting the gnuk from the BP, plugging it into my USB port and seeing it come up successfully:
usb 1-2: new full-speed USB device number 11 using xhci_hcd
usb 1-2: New USB device found, idVendor=234b, idProduct=0000
usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 1-2: Product: Gnuk Token
usb 1-2: Manufacturer: Free Software Initiative of Japan
usb 1-2: SerialNumber: FSIJ-1.1.7-87063020
usb 1-2: ep 0x82 - rounding interval to 1024 microframes, ep desc says 2040 microframes
More once I actually have a 4K key loaded on it.
systemctl restart
doing more than systemctl stop ; systemctl
start
. You will notice the difference once you have a failed service. A
restart
will try to start the service again. Both stop
and start
however will just ignore it. Rumors have it this has changed post
jessie however.
sysvinit-wrapped services and stop
While there are certainly bugs with sysvinit services in general (I
found myself several times without a local resolver as unbound
failed to be started, haven't managed to debug further), the stop
behavior of wrapped services is just broken. systemctl stop
will
block until the sysv initscript finished. It will even note the result
of the action in its state. However systemctl will return with
exitcode 0 and not output anything on stdout/stderr. This has been
reported as
Debian Bug.
zsh helper
I found the following zshrc snipped quite helpful in dealing with
non-reported systemctl
failures. On root shells it will display a
list of failed services as part of the prompt. This will give proper
feedback whether your systemctl stop
failed, it will give feedback
if you still have type=simple
services and if the sysv-init script
or wrapper is broken.
precmd ()
if [[ $UID == 0 && $+commands[systemctl] != 0 ]]
then
use_systemd=true
systemd_failed=" systemctl --state=failed grep failed cut -d \ -f 2 tr '\n' ' ' "
fi
if [[ $UID == 0 && $+commands[systemctl] != 0 ]]
then
PROMPT=$'% $fg[red]>> $systemd_failed$reset_color% \n'
else
PROMPT=""
fi
PROMPT+=whateveryourpromptis
zsh completion
Speaking of zsh, there's one problem that bothers me a lot and I don't
have any solution for. Tab-completing the service name for service
is
blazing fast. Tab-completing the service name for systemctl restart
takes ages. People traced down to truckloads of dbus communication for
the completion but no further fix is known (to me).
type=simple services
As described in length by
Lucas Nussbaum
type=simple
services are actively harmful. Proper type=forking
daemons are strictly superior (they provide feedback of finished
initialization and success thereof) and type=notify
services are so
simple there's no excuse for not using them even for private one-off
hacks. Even if you're language doesn't provide libsystemd-daemon
bindings:
(defun sd-notify (event-string)
(let ((socket (make-instance 'sb-bsd-sockets:local-socket :type :datagram))
(name (posix-getenv "NOTIFY_SOCKET"))
(bufferlen (length event-string)))
(when name
(sb-bsd-sockets:socket-connect socket name)
(sb-bsd-sockets:socket-send socket event-string bufferlen))))
This is a
stable API
guaranteed to not break in the future and implemented in less than ten
lines of code with just basic socket functions. And if your language
has support it becomes actually trivial:
try:
import systemd
systemd.daemon.notify("READY=1")
except ImportError:
pass
Note that in both cases there is no drawback at all on systemd-free
setups. It has the overhead of checking the process' environment for
NOTIFY_SOCKET
or for the systemd
package and behaves like a simple
service otherwise.
Actually the idea of separating the technical aspect (daemonizing)
from the semantic aspect of signalizing "initialization finished,
everything's fine" is a pretty good idea and hopefully has the
potential to reduce the number of services signalizing the
"everything's fine" too early. It could even be ported to non-systemd
init systems easily given the API.
systemctl restart
doing more than systemctl stop ; systemctl
start
. You will notice the difference once you have a failed service. A
restart
will try to start the service again. Both stop
and start
however will just ignore it. Rumors have it this has changed post
jessie however.
sysvinit-wrapped services and stop
While there are certainly bugs with sysvinit services in general (I
found myself several times without a local resolver as unbound
failed to be started, haven't managed to debug further), the stop
behavior of wrapped services is just broken. systemctl stop
will
block until the sysv initscript finished. It will even note the result
of the action in its state. However systemctl will return with
exitcode 0 and not output anything on stdout/stderr. This has been
reported as
Debian Bug #792045.
zsh helper
I found the following zshrc snipped quite helpful in dealing with
non-reported systemctl
failures. On root shells it will display a
list of failed services as part of the prompt. This will give proper
feedback whether your systemctl stop
failed, it will give feedback
if you still have type=simple
services and if the sysv-init script
or wrapper is broken.
precmd ()
if [[ $UID == 0 && $+commands[systemctl] != 0 ]]
then
use_systemd=true
systemd_failed=" systemctl --state=failed grep failed cut -d \ -f 2 tr '\n' ' ' "
fi
if [[ $UID == 0 && $+commands[systemctl] != 0 ]]
then
PROMPT=$'% $fg[red]>> $systemd_failed$reset_color% \n'
else
PROMPT=""
fi
PROMPT+=whateveryourpromptis
zsh completion
Speaking of zsh, there's one problem that bothers me a lot and I don't
have any solution for. Tab-completing the service name for service
is
blazing fast. Tab-completing the service name for systemctl restart
takes ages. People traced down to truckloads of dbus communication for
the completion but no further fix is known (to me).
type=simple services
As described in length by
Lucas Nussbaum
type=simple
services are actively harmful. Proper type=forking
daemons are strictly superior (they provide feedback of finished
initialization and success thereof) and type=notify
services are so
simple there's no excuse for not using them even for private one-off
hacks. Even if you're language doesn't provide libsystemd-daemon
bindings:
(defun sd-notify (event-string)
(let ((socket (make-instance 'sb-bsd-sockets:local-socket :type :datagram))
(name (posix-getenv "NOTIFY_SOCKET"))
(bufferlen (length event-string)))
(when name
(sb-bsd-sockets:socket-connect socket name)
(sb-bsd-sockets:socket-send socket event-string bufferlen))))
This is a
stable API
guaranteed to not break in the future and implemented in less than ten
lines of code with just basic socket functions. And if your language
has support it becomes actually trivial:
try:
import systemd
systemd.daemon.notify("READY=1")
except ImportError:
pass
Note that in both cases there is no drawback at all on systemd-free
setups. It has the overhead of checking the process' environment for
NOTIFY_SOCKET
or for the systemd
package and behaves like a simple
service otherwise.
Actually the idea of separating the technical aspect (daemonizing)
from the semantic aspect of signalizing "initialization finished,
everything's fine" is a pretty good idea and hopefully has the
potential to reduce the number of services signalizing the
"everything's fine" too early. It could even be ported to non-systemd
init systems easily given the API.
Week 1 | Week 2 | Week 3 | Week 4 | Week 5 | Week 6 | Week 7 | |
---|---|---|---|---|---|---|---|
# Packages | 10 | 15 | 10 | 14 | - | - | - |
Total | 10 | 25 | 35 | 49 | - | - | - |
Dpkg::Dist::Files
files list on output to make the output stable with parallel builds.xpi-pack
to skip saving extra zip attributes when making jar.sort
in the buildinfo generator prevented a stable order and was quickly
fixed once identified.
Mattia Rizzolo also rebased our custom
debhelper on the latest release.
Packages fixed
The following 30 packages became reproducible due to changes in their
build dependencies:
animal-sniffer,
asciidoctor,
autodock-vina,
camping,
cookie-monster,
downthemall,
flashblock,
gamera,
httpcomponents-core,
https-finder,
icedove-l10n,
istack-commons,
jdeb,
libmodule-build-perl,
libur-perl,
livehttpheaders,
maven-dependency-plugin,
maven-ejb-plugin,
mozilla-noscript,
nosquint,
requestpolicy,
ruby-benchmark-ips,
ruby-benchmark-suite,
ruby-expression-parser,
ruby-github-markup,
ruby-http-connection,
ruby-settingslogic,
ruby-uuidtools,
webkit2gtk,
wot.
The following packages became reproducible after getting fixed:
debian/changelog
as build date.debian/changelog
as documentation build date.debian/changelog
as reference.debian/changelog
as build date.debian/changelog
as documentation build date.Storable::nstore
to produce sorted output.DATE
, WHOAMI, and
HOSTNAME_CMD to stable values.debian/changelog
as documentation build date.debian/changelog
as documentation build date.debian/changelog
as documentation build date.deadwood
binary.--distrobuild
build switch.locales-all
is installed instead of locales
.debbindiff
.pom.properties
files.
debbindiff development
At the request of Emmanuel Bourg, Reiner Herrmann added a comparator for Java
.class
files.
Documentation update
Christoph Berg created a new page for the timestamps in manpages created by
Doxygen.
Package reviews
93 obsolete
reviews have
been removed, 76 added and 43 updated this week.
New identified issues: timestamps in manpages generated by Doxygen, modification time differences in files extracted by unzip, tstamp task used in Ant build.xml, timestamps in documentation generated by ASDocGen. The description for build id related issues has been clarified.
Meetings
Holger Levsen announced a first
meeting on Wednesday,
June 3rd, 2015, 19:00 UTC. The agenda is amendable on the wiki.
Misc.
Lunar worked on a proof-of-concept script to import the build environment found
in .buildinfo
files to
UDD. Lucas Nussbaum has positively reviewed the
proposed schema.
Holger Levsen cleaned up various experimental toolchain repositories, marking
merged brances as such.
If set to simple (the default value if neither Type= nor BusName= are specified), it is expected that the process configured with ExecStart= is the main process of the service. In this mode, if the process offers functionality to other processes on the system, its communication channels should be installed before the daemon is started up (e.g. sockets set up by systemd, via socket activation), as systemd will immediately proceed starting follow-up units. In other words, systemd just runs the command described in ExecStart=, and it s done: it considers the service is started. Unfortunately, this causes a regression compared to the sysvinit behaviour, as described in #778913: if there s a configuration error, the process will start and exit almost immediately. But from systemd s point-of-view, the service will have been started successfully, and the error only shows in the logs:
root@debian:~# systemctl start ssh root@debian:~# echo $? 0 root@debian:~# systemctl status ssh ssh.service - OpenBSD Secure Shell server Loaded: loaded (/lib/systemd/system/ssh.service; enabled) Active: failed (Result: start-limit) since mer. 2015-05-13 09:32:16 CEST; 7s ago Process: 2522 ExecStart=/usr/sbin/sshd -D $SSHD_OPTS (code=exited, status=255) Main PID: 2522 (code=exited, status=255)
mai 13 09:32:16 debian systemd[1]: ssh.service: main process exited, code=exited, status=255/n/a mai 13 09:32:16 debian systemd[1]: Unit ssh.service entered failed state. mai 13 09:32:16 debian systemd[1]: ssh.service start request repeated too quickly, refusing to start. mai 13 09:32:16 debian systemd[1]: Failed to start OpenBSD Secure Shell server. mai 13 09:32:16 debian systemd[1]: Unit ssh.service entered failed state.With sysvinit, this error is detected before the fork(), so it shows during startup:
root@debian:~# service ssh start [....] Starting OpenBSD Secure Shell server: sshd/etc/ssh/sshd_config: line 4: Bad configuration option: blah /etc/ssh/sshd_config: terminating, 1 bad configuration options failed! root@debian:~#It s not trivial to fix that. The implicit behaviour of sysvinit is that fork() sort-of signals the end of service initialization. The systemd way to do that would be to use Type=notify, and have the service signals that it s ready using systemd-notify(1) or sd_notify(3) (or to use socket activation, but that s another story). However that requires changes to the service. Returning to the sysvinit behaviour by using Type=forking would help, but is not really a solution: but what if some of the initialization happens *after* the fork? This is actually the case for sshd, where the socket is bound after the fork (see
strace -f -e trace=process,network /usr/sbin/sshd
), so if another process is listening on port 22 and preventing sshd to successfully start, it would not be detected.
I wonder if systemd shouldn t do more to detect problems during services initialization, as the transition to proper notification using sd_notify will likely take some time. A possibility would be to wait 100 or 200ms after the start to ensure that the service doesn t exit almost immediately. But that s not really a solution for several obvious reasons. A more hackish, but still less dirty solution could be to poll the state of processes inside the cgroup, and assume that the service is started only when all processes are sleeping. Still, that wouldn t be entirely satisfying
Next.